1. Technical Field
This invention generally relates to object oriented programming and more specifically relates to a mechanism and method for defining a desired processing environment in an object oriented framework.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object oriented programming concepts. The goal of using object oriented programming is to create small, reusable sections of program code known as "objects" that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
A central concept in object oriented programming is the "class." A class is a template that defines a type of object. A class outlines or describes the characteristics or makeup of objects that belong to that class. By defining a class, objects can be created that belong to the class without having to rewrite the entire definition for each new object. This feature of object oriented programming promotes the reusability of existing object definitions and promotes more efficient use of program code.
Frameworks are relatively recent developments in object oriented programming that provide a group of pre-packaged classes and class relationships that are designed to help a user easily extend the framework to write a particular software program, such as a software application. Frameworks typically define certain core functions that cannot be changed by a programmer using the framework, and allow the programmer to extend the framework at defined extension points to generate a custom software application in much less time than coding the software application from scratch.
The function of a software application can be thought of as a series of "processes". Some of these processes may have time-order dependence on other processes. For example, the output from one process may be used as the input to one or more subsequent processes. These processes may need to be combined in different ways depending upon the applicable rules for the particular software application and depending on the type of data being processed. A software application that is developed from scratch typically has the order of processes and their interrelationship hard-coded. A software application developed from most framework mechanisms has the order of processes and their interrelationship defined by some extent by the core functions of the framework, limiting the amount of customization available to a programmer who extends the framework.
Frameworks may be very general or can be a very specific solution to a particular problem. Framework developers typically make trade-offs between the number of functions the framework supports and the flexibility in using the framework. The more functions that are built into the core functions of the framework, the less time a programmer has to spend generating code to extend the framework. However, more functions generally mean a more detailed implementation within the framework itself, which typically reduces the ability to adapt the framework to different circumstances. Fewer core functions in the framework generally makes the framework more flexible, but decreases the power of the framework, putting more of a programming burden on the user that extends the framework to define a software application. Most frameworks try to balance performance with flexibility by defining core aspects of a specific problem within the framework, while allowing user customization of domain-specific information in the extensions to the framework. This approach can lead to a variety of different frameworks that are each targeted for specific types of software applications. For example, a framework for performing computer system diagnostics may have many different core functions than a framework for order processing. However, even a single type of application, such as order processing, can have a wide variety of different steps and orders of those steps that vary greatly according to the specific type of business and rules that the business has in place.
Examples of a few different types of order processing systems will illustrate the diversity of possible order processing systems. For a mail-order company that bills their customers after shipping the goods, the order processing may be represented at a high level by the following sequence of processes: 1) generate order; 2) pick order; 3) ship order; 4) generate invoice; and 5) confirm payment. A mail-order company that requires payment before shipping the goods may have a different order processing sequence: 1) generate order; 2) confirm payment; 3) generate invoice; 4) pick order; and 5) ship order. In this latter example, the generation of the invoice is done before the item is picked or shipped. A retail company typically has in-store stock, so the steps of picking and shipping the order are not required. Thus, the process steps and order of steps can vary greatly from one order processing system to the next. These examples serve to illustrate the point that virtually endless numbers and combinations of steps are possible in order processing, and in many other type of processing environments.
One solution to the wide array of possible combinations in order processing is to provide a framework that defines specific steps for a particular type of order processing. This solution would require three separate frameworks for the three order processing scenarios presented above. However, generating three separate frameworks for three different types of order processing essentially ignores the common features that exist in most order processing systems.
IBM has introduced a framework known as San Francisco that defines processes that may be flexibly coupled together. These flexibly coupled processes are described in co-pending U.S. patent application Ser. No. 09/162,719 entitled "Mechanism And Method For Flexible Coupling of Processes in an Object Oriented Framework", filed by Carlson et al. on Sep. 29, 1998. This related patent application describes the mechanism that provides the interfaces that allow processes to be flexibly coupled together. However, without a mechanism for coupling these processes together to define a desired processing environment, the processes that support flexible coupling will be of no use.